PackML was written for packaging machinery. The name says so. It came out of OMAC in the early 2000s as a way to stop every packaging OEM from inventing its own state machine, and it succeeded well enough that ISA adopted it as part of ISA-TR88.00.02. So why are controls engineers on machining cells, robotic assembly lines, and end-of-line test stands now writing PackML state machines into their PLC code, on equipment that has never touched a carton or a case pack?
Because the actual problem PackML solves has nothing to do with packaging. It solves the problem of a SCADA system or MES needing to ask a machine “what are you doing right now, and can I trust the answer,” and getting a consistent response regardless of who built the machine or what language the PLC program is written in. That problem exists everywhere in discrete manufacturing, not just on a case packer. If you’ve ever tried to calculate OEE across a mixed line of a CNC cell, a manual assembly station, and a vision-based test fixture, and gotten three different flavors of “running” and “not running” from three different control philosophies, you already understand why PackML is leaking out of its original domain.
What you’re actually borrowing
PackML gives you two things worth separating in your head. One is the state model itself — Idle, Starting, Execute, Completing, Held, Suspended, Stopping, Stopped, Aborting, Aborted, Resetting, Clearing — with defined transitions between them. The other is PackTags, the standardized data structure (mode, machine speed, unit counts, alarm status) meant to ride on top of that state model so a SCADA screen or historian knows where to look regardless of vendor.
Most of the discrete-manufacturing adoption I’d point to is borrowing the state model and quietly leaving the full PackTags implementation on the shelf. That’s a reasonable trade. The state model is the part that solves your integration problem. The full tag dictionary is the part that starts to feel like paperwork if your MES already has its own data contract for a machine interface.
Where the mapping is genuinely clean
On equipment that runs a repeating cycle against a fixed recipe or program — a CNC machining center, a robotic weld cell, a leak tester, a torque station — PackML’s states map almost one-to-one onto what the machine is already doing internally:
- Idle maps to a cell waiting for a part present signal or a start command, with no active operation.
- Execute maps to the cycle actually running — spindle turning, robot moving, test in progress.
- Held maps cleanly to an automatic pause that the process itself can recover from — think an interlock gate opened mid-cycle, or a part-present sensor dropping out — without operator intervention beyond clearing the condition.
- Suspended maps to an upstream or downstream starvation/blocking condition: the cell is fine, but it can’t run because the next station is full or the previous one hasn’t delivered a part. This is the state most legacy discrete PLC programs never explicitly modeled, and it’s the single biggest win PackML brings to a discrete line — it’s exactly the distinction an OEE calculation needs between “the machine is broken” and “the machine is starved.”
- Stopping/Stopped/Resetting map well onto a normal end-of-job or changeover sequence.
If your discrete equipment already has some version of a cycle-start/cycle-complete/fault state machine buried in ladder logic or structured text, you’re not building something new. You’re renaming and reorganizing something that already exists into a shape that SCADA and MES can read without a custom driver for every cell.
Where it starts to strain
PackML’s Aborted/Aborting states and its recipe-and-mode framing assume a machine running a defined “product” through a defined sequence, which is a packaging-line assumption more than a universal one. Manual and semi-automated assembly stations are the clearest failure point: a human operator doesn’t cleanly occupy Execute for the duration of a manual build step, and forcing operator-paced work into an automated cycle-state model produces states that are technically populated but not meaningful for OEE math. You end up with a line that reports “Execute” while someone is manually torquing a fastener at their own pace, which tells you almost nothing about whether the station is actually a bottleneck.
Test cells with branching logic — pass/fail routing, retest loops, multiple recipe paths triggered by upstream data — also stretch the model. PackML expects a state machine, not a decision tree, and bolting conditional routing onto Execute without a clear convention turns your “standard” state machine into another bespoke integration in disguise.
The honest fix in both cases is to stop treating PackML as a universal skin and instead ask, station by station, whether the underlying behavior is actually cyclic and machine-paced. Where it is, use the model as designed. Where it isn’t, don’t force it — model the manual or branching behavior with its own logic and only surface a PackML-compatible summary state at the boundary where SCADA/MES needs to see it.
Building it so SCADA and MES agree on what they’re looking at
The failure mode I’d flag loudest for PLC programmers picking this up ad hoc: implementing the state model as an internal convenience without exposing it as a single, unambiguous tag that downstream systems consume consistently. If your SCADA screen infers “Execute” from one combination of bits and your MES infers it from another, you’ve recreated the exact inconsistency PackML was supposed to kill — just with better state names.
A few structural choices matter more than people expect:
- Implement the state machine as an actual enumerated integer or named state, not as a set of loosely related booleans that something downstream has to reverse-engineer. One tag, one source of truth, exposed over whatever your integration layer is — OPC UA is the natural fit, and it plays well with the way most modern MES and historian connectors expect equipment state to be surfaced.
- Define transitions explicitly in your logic, including the ones nobody likes writing, like what forces a return to Idle after an Abort versus after a normal Stop. Undefined transition paths are where downstream OEE math silently goes wrong.
- Decide early, and document, what counts as machine-caused downtime (Held) versus line-caused downtime (Suspended) for your specific cells, and hold that line consistently across every station type on the line. Inconsistent judgment calls here are the most common reason PackML-based OEE numbers don’t match what the plant floor believes is true.
- Resist expanding the state model per station. The value of PackML is cross-line consistency; a “PackML-inspired” state machine that differs subtly cell to cell gives you the maintenance burden of a standard without the benefit of one.
Skip the full batch build-out — deliberately
The reason PackML is winning this ground over a full ISA-88 batch implementation isn’t that ISA-88 is wrong for discrete manufacturing — it’s that most discrete lines don’t have the recipe-and-phase complexity that justifies ISA-88’s overhead. PackML gives you the state-reporting discipline without asking you to model procedures, unit procedures, operations, and phases for a line that’s really just running one program per part family. For plants standardizing state reporting across a heterogeneous discrete line for OEE and line-integration purposes, that’s the right amount of structure: enough to get vendor-independent, MES-legible equipment states, not so much that every controls engineer needs an ISA-88 course before touching the PLC.
Use PackML where your equipment is genuinely cyclic and machine-paced. Model manual and branching stations honestly rather than forcing them into states that don’t fit. And treat the state tag as a contract with SCADA and MES, not an internal convenience — because the whole point of borrowing someone else’s standard is that you don’t get to quietly redefine it halfway through the line.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
